System and method for administering security in a corporate portal

ABSTRACT

A method, system, and computer program product for corporate portal security are provided, wherein security information corresponding to an external object imported into the corporate portal is automatically mapped from the object&#39;s native security system into the corporate portal system. For each external object imported, the corporate portal maps external users and external groups identified by the native security into corresponding portal users and portal groups according to a predefined mapping process, and stores the results in a manner that associates the external object with those portal users and portal groups. A plurality of database tables and maps determines the outcome of the predefined mapping process. Advantageously, when new external users or groups are added, they are detected by a synchronization agent which then automatically updates the database tables and maps. When custom group security configurations are desired, or when new domains are added, the portal administrator may manipulate a subset of the database tables and maps to achieve the desired configuration. Advantageously, manually intensive operations such as object-by-object security stampings, and/or re-manipulation of individual security settings associated with re-instantiated crawls, are avoided.

PRIORITY

This application is a continuation application of U.S. patentapplication Ser. No. 09/896,039, filed Jun. 29, 2001, and is herebyincorporated by reference.

FIELD OF THE INVENTION

This patent specification relates to portal systems. In particular, itrelates to a system and method for administering security in a corporateportal.

BACKGROUND OF THE INVENTION

It is common for today's enterprise networks to comprise scatteredarrangements of different hardware and software systems. This is due tothe ever-changing data management needs of corporate enterprises, and tocontinuing advances in the computing hardware and software available tomeet those needs. Commonly, different entities within an enterprise(e.g., different departments or work sites) have disparate softwareapplications, groupware systems, or data maintenancearchitectures/procedures, such that information created or maintained byone entity is not usable by another entity.

Corporate portals, also referred to as intranet portals, have beenintroduced to increase the accessibility and usability of informationstored across heterogeneous systems of an enterprise network. Acorporate portal, which is usually overlaid onto an existing enterprisenetwork, is designed to extract content from disparate systems on theenterprise network, and to make that content searchable. The corporateportal is further designed to subdivide the content into taxonomiccategories useful to the enterprise, and to allow individual users toaccess the content using an intuitive, customizable user interface. Thecustomizable user interface is usually web-based to enhance itsintuitiveness.

As part of the customization process, the user may configure theirdisplay to include one or more portal processing objects. Portalprocessing objects are adapted to access, process, and display contentin a predefined manner appropriate for a class of user. For example, acompany executive might import a first portal processing object into herdisplay that illustrates certain sales data in a quarterly summaryformat. In contrast, a field sales supervisor might import a secondportal processing object into his display that shows a real-time“streaming” version of that sales data.

A corporate portal comprises a database, such as a relational database,for storing the organizational schema of the enterprise. To maintain ataxonomic structure for organizing access to content, the corporateportal stores the names of categories and the references to contentassociated with those categories in a database. Due to storagelimitations, and the problems associated with replicating content to asingle format, a corporate portal may not store all of the contentaccessible from the portal. Rather, only references to that content arestored.

A corporate portal further comprises a search engine to automate theorganization of text-based content. The search engine allows users toperform general searches for desired content contained across the manyheterogeneous systems of an enterprise network.

A corporate portal further comprises a metadata-driven utility toautomate the organization of different types of structured content.Corporate portals organize access to structured content including, forexample, enterprise resource planning records, data warehousing reports,extensible markup language content, and groupware documents. Suchcontent is often described by metadata that an application stores ascolumns, fields, or tags to describe the actual data, often for thebenefit of other applications or an administrator. Using metadata toorganize content provides for meaningful, integrated access to the manyrepositories of structured information that contain little text.Evaluating metadata also increases the precision of the organizingutility for semi-structured content, which consists of both metadata andtext. Because metadata formats and terminology vary, the corporateportal is designed to recognize a wide variety of metadata. Once themetadata is understood in a standard form, the corporate portal candisplay that information with each reference, much like a card in a cardcatalog displays the author, subject and title of books in a collection.

Finally, a corporate portal incorporates web publishing tools similar tomany document publishing and conversion tools. The portal publishes ataxonomy of content references, but may not necessarily publish thecontent itself in an HTML format. When a user clicks on a link, theportal may open desktop tools such as a Lotus Notes client or a databasequery tool instead of a web page, depending on the user's preferenceand/or privileges.

One example of a corporate portal is the Plumtree Corporate Portal 4.0available from Plumtree Software, Inc. of San Francisco, Calif. Aspectsof the Plumtree Corporate Portal 4.0 are described in a publiclyavailable document, entitled “The Plumtree Corporate Portal 4.0:Technical White Paper,” which is available from Plumtree Software, Inc.and which is posted on their public web site at plumtree.com as of thefiling date of this disclosure.

Desirable attributes of a corporate portal system include the ability toextract information from a wide variety of different formats (e.g.,MICROSOFT OFFICE™, LOTUS NOTES™, VISIO™, HTML, ADOBE PDF™, etc.), andthe ability to organize access to that information in a meaningfulmanner appropriate for the enterprise. A further desirable attribute ishigh extensibility, i.e., the ability to be extended to accommodate andbring together many heterogeneous enterprise network systems. Inaddition to being important during high corporate growth periods ormerger activity, extensibility is also important for “future-proofing”of the corporate portal, such that information systems and data formatsnot currently in existence can be accommodated in the future. Yetanother important attribute is security, wherein access to sensitiveinternal information is selectively brokered among different classes ortypes of employees, or selectively provided to certain users outside thecompany.

Finally, another crucial feature of a corporate portal is ease ofadministration. It is important that the person or persons administeringand maintaining the corporate portal be provided with easy-to-use toolsfor keeping the corporate portal up-to-date, secure, and comprehensive,without requiring extensive manual upkeep and intervention. Statedanother way, manual effort by a portal administrator should not bewasted on excessively tedious or repetitive tasks.

FIG. 1 shows a corporate portal configuration in accordance with theprior art, comprising a corporate portal system 102 overlaid onto anenterprise network 104. It is to be appreciated that enterprise network104 of FIG. 1 is a simplified example, and that the preferredembodiments described herein are applicable to enterprise networks thatmay comprise many heterogeneous sub-networks or domains across manydifferent work groups or spanning many different work sites connected bya wide area network. It is to be further appreciated that whiledifferent domains are often physically collocated or intermingled inpractice, depending on their purposes and distinctions, differentdomains herein are shown as physically separate collections for clarityof presentation. In the simplified example of FIG. 1, enterprise network104 comprises a communications backbone 106, a marketing domain 108, anengineering domain 110, and one or more miscellaneous nodes 112 (e.g.,receptionist, executive, etc.). Enterprise network 104 is usuallyconnected to the Internet 114. Marketing domain 108 comprises marketinggroupware 109, a marketing archive 118, and a plurality of userterminals 120, such as personal computers, for use by marketingpersonnel. Engineering domain 110 comprises engineering groupware 122,an engineering archive 124, and a plurality of user terminals 126, suchas personal computers or engineering workstations, for use byengineering personnel.

Generally speaking, due to different computing needs and/or differentevolutionary paths within the enterprise, the marketing domain 108 andengineering domain 110 often contain vastly different types of computinghardware and software. Thus, for example, the marketing domain 108 maybe based on a Lotus Notes groupware architecture, whereas theengineering domain 110 may be based on a Windows NT network platform.Each of these domains will usually maintains its own lists of users andgroups in its own distinct format. Still other domains (not shown) ofthe enterprise network 104 may maintain lists of users and groupsaccording to a standardized format such as LDAP (Lightweight DirectoryAccess Protocol). As known in the art, user refers to a particularperson using the system (e.g., Bob, Mary, Steve, etc.), while a grouprefers to a logical collection of users (e.g., Executives, Engineers,Marketing, Company_Picnic_Committee, etc.). As used herein, “externalusers” and “external groups” refer to users and groups as identified bytheir native domains. In contrast, “portal users” and “portal groups”refers to users and groups as identified by the corporate portal system102.

Corporate portal system 102 comprises a web server 128, a portalprocessing object server 130, a job server 132, a first data storageserver 134, and a second data storage server 136 coupled as shown inFIG. 1. It is to be appreciated that the elements 128-136 are shown onseparate hardware systems and coupled over a network due to practicalimplementation requirements. However, the different elements ofcorporate portal 102 may be implemented on different combinations ofhardware and networking connections, and may even be implemented on asingle computing machine, although such a configuration is generally notrecommended for performance reasons.

Portal processing object server 130 has a connection to web server 128for performing the role of serving requests from portal processingobjects being executed for portal users. Job server 132 comprises asearch engine 138 and a file crawler 140. Data storage server 134comprises a relational database 142 into which is stored directorytables 146 comprising metadata about selected objects (e.g., documents,databases, executables, and other objects) contained in the enterprisenetwork 104 (hereinafter referred to as “external objects” because theyare external to the corporate portal). The contents of directory tables146 forms a metadata object corresponding to each external object, oftenreferred to as a card for that external object. Relational database 142further comprises an access control list 144 comprising, for eachexternal object, a list of the portal users and portal groups that mayaccess that object. The second data storage server 136 comprises a textindex 150 used in conjunction with the search engine 138, and a set ofportal processing object snapshots 152 for use by the portal processingobject server 130.

In operation, when the file crawler 140 (which may comprise Notes,Exchange, web crawlers, etc.) discovers a new document (or other newobject) in the enterprise network 104, the document is given an objectidentifier (OID). The document is also text-indexed by search engine138, with the resulting data stored in text index 150. Also, metadatacorresponding to the new document (e.g., title, location, author,creation date, type, and many other attributes) is stored in directorytables 146 to form a metadata object (i.e., card) 148 for that document.For clarity of explanation, the examples presented herein are for acommon situation in which newly discovered object is a document, such asa word processing file, HTML file, spreadsheet file, or the like. It isto be appreciated, however, that the newly discovered object maygenerally be any type of object (e.g., XML file, executable, databasefile, directory object, groupware related reference files, executables,or objects, etc.) in accordance with the preferred embodiments describedherein.

Finally, after indexing and metadata object creation, the access controllist 144 is updated to include the object identifiers (OIDs) of theportal users and portal groups that may access that document. Forclarity of explanation, the presence of an OID associated with adocument, user, group, or other object is established herein byreference to the object name itself. Thus, for example, a reference to auser (cn=John, OID=0×f9c6b332) shall simply be “John,” it beingunderstood that the corporate portal system will actually be storing ormanipulating the OID corresponding to John. When a user logs onto thecorporate portal and performs a search, a first set of documents maysatisfy their search parameters. For each document in that set, theaccess control list 144 is checked to see if that portal user has accesspermission to that document, or if that user is a member of a portalgroup having access permission to that document. The portal user is onlypresented with a listing of documents for which they have accesspermission.

More particularly, the portal user is presented with informationselected from the metadata object corresponding to that document (e.g.,document title, author, abstract, hyperlink to the document, etc.). Theportal user may then instantiate a document viewing session, in whichweb server 128 accesses the document from its location on the enterprisenetwork 104 and presents it to the user in a browser window.Alternatively, depending on the configuration of that specific corporateportal for that user, the user may be required to separately log in tothe domain containing the document (using an external user name andpassword) and view it using their own desktop software applications.Many other scenarios are possible depending on the configuration of thecorporate portal 102 and the enterprise network 104. For purposes of thepresent disclosure, it is mainly important to note that documents towhich a portal user does not have access permission are kept invisibleto that portal user by the corporate portal 102.

Problems arise in the administration of the prior art corporate portal102 with respect to the administration of the access control list. Inparticular, a disadvantageous trade-off is presented between properdocument security settings in the access control list versus the amountof corporate portal system administrator time and effort required tomaintain it. According to the prior art of FIG. 1, the file crawlingsessions that discover new documents and populate the access controllist (often referred to as “crawls”) are administered by contentmanagers 154 and 156. For example, the content manager 154 may beresponsible for marketing content present on the corporate portalsystem, while the content manager 156 may be responsible for engineeringcontent present on the corporate portal system. Content managers 154 and156 are expected to have a close connection to the content and users intheir particular area of responsibility. More particularly, contentmanagers 154 and 156 are expected to have a practical knowledge of theexternal users and external groups that may be associated withdocuments' native security settings, and a practical knowledge of howthose settings should be reflected in the corporate portal securitysystem with respect to portal users and portal groups.

FIG. 2 shows steps for crawling and assigning document security settingsin accordance with the prior art. At step 202, the content managerconfigures crawl parameters. For example, the content manager willspecify the domains, directories, file types, etc. for a crawl. Thecontent manager may specify that the crawl be executed on a one-timebasis, on a regular periodic basis (e.g., nightly, weekly), or accordingto a custom schedule. At step 204, while configuring the crawlparameters, the content manager specifies the security settings for thedocuments that will be imported by that crawl, in particular specifyingthe portal users and portal groups that will have access to the importeddocuments. After crawling begins, at step 206 the file crawler finds anew document meeting the crawl parameters, and at step 208 the documentis imported into the corporate portal through the generation and storageof an associated metadata object in the relational database 142. At step210, the document is “stamped” with access permissions, i.e., the accesscontrol list 144 is populated for that document according to thepre-specified portal users and portal groups specified by the contentmanager. At step 212, the content manager reviews the crawl results, andmay manually change access settings in the access control list 144 ifrequired.

Disadvantageously, the method of FIG. 2 results in corporate portalsecurity settings having limited precision and extensibility. First, thesecurity for each document imported into the corporate portal isextrinsically dictated by the corporate portal system itself (via thecontent manager), rather than by external network administrator orexternal user who created the document. In large corporations, thecontent manager may be substantially removed from an understanding ofthe access control required for documents in a given location. While thecontent manager might attempt to access and emulate the local securitysettings for documents, this would be manually intensive task that ismade even more difficult by the many heterogeneous security systems inthe enterprise network. Often, the content manager will take the “saferoad” and provide very limited access to crawled documents (e.g., bydoing per-domain crawls and only allowing portal groups corresponding tothat specific domain to view the document). This can defeat the verypurpose of the corporate portal system, which is to enhance intelligenceand best-practices sharing among the enterprise network users.Alternatively, the content manager might “throw their hands up” andallow every portal group to see the document, which might compromisecorporate security policies. Accordingly, if the content administratoris unwilling or unable to shoulder an intensive, laborious workload inproperly keeping up the access control list, the appropriateness of thesettings in the access control list suffers.

Furthermore, the extensibility of the corporate portal security settingsis limited in the prior art method of FIG. 2. It is often the case thatentire domains, users, and groups are added to the corporate portal allat once (e.g., in a corporate acquisition or merger scenario). In such asituation, members of newly added portal groups will generally not beable to view currently existing documents in the corporate portalsystem, unless a new set of crawls is performed, wherein new customparameters must be added specifying which of the newly added portalgroups should see the documents, in addition to any old customparameters for current portal groups. Alternatively, the content managermay individually “stamp” the newly allowed portal groups onto the cardsof the existing documents. Either of these scenarios represents asubstantial, administration-intensive task. Similar tasks would alsoneed to be performed on new documents from the added domain with respectto portal groups that were already in existence.

Accordingly, it would be desirable to provide a corporate portal inwhich security settings are more easily administered.

It would be further desirable to provide a corporate portal in whichobject security settings are established and maintained with increasedprecision and relevance.

It would be still further desirable to provide a corporate portalsecurity system that is more extensible and does not require excessivemanual intervention upon the addition of new domains, users, or groupsto the enterprise network.

SUMMARY OF THE INVENTION

A method, system, and computer program product for corporate portalsecurity are provided, wherein security information corresponding to anexternal object imported into the corporate portal is automaticallymapped from the object's native security system into the corporateportal system. Importation of the external object includes the steps ofgenerating a metadata object corresponding to the external object andstoring the metadata object in a database of the corporate portal. Themapped security information is also stored in the portal database, or inan associated database. For a given external object for which thecorporate portal has an associated metadata object and a body of mappedsecurity information, portal user information is compared in real-timeto the mapped security information to determine whether to expose theassociated metadata object to that portal user. In one preferredembodiment, the mapped security information comprises read accesspermissions of portal users and portal groups.

For a given external object, the native security system maintains accesspermissions in terms of external users and external groups. According toa preferred embodiment, the corporate portal maps the external users andexternal groups into corresponding portal users and portal groupsaccording to a predefined mapping process, and stores the results in amanner that associates the external object with those portal users andportal groups. In one preferred embodiment, the results are stored in anobject security table in the portal database.

Information affecting the predefined mapping process is stored in aplurality of tables in the portal database, including a user profiletable, a group profile table, and a group membership table. Portal usersare identified in entries of the user profile table by a concatenationof a portal domain identifier and a user name used by the nativeexternal domain for that user. Portal groups are identified in entriesof the group profile table by a concatenation of a portal domainidentifier and a group name used by the native external domain for thatgroup. The group membership table maps the portal user identifiers intothe portal group identifiers according to known group membershipinformation.

Further information affecting the predefined mapping process is storedin an access control synchronization map in the portal database. Theaccess control synchronization map comprises a domain synchronizationmap and a group synchronizations map. The domain synchronization mapcomprises external domain entries mapped into portal domains. The groupsynchronization map comprises external group names mapped into portalsimple group names. The contents of the domain synchronization map and agroup synchronizations map may be manipulated by a portal administratorsuch that desired mappings from external users and external groups toportal users and portal groups is achieved.

Advantageously, when new users or groups are added to the enterprisenetwork, they can be automatically detected by a synchronization agent,which then automatically populates the user profile table, group profiletable, and group membership table. These new users and/or groups areautomatically accommodated during subsequent importations of securitysettings associated with imported objects into the object securitytable, unless optional custom security settings are desired. Whenoptional custom security settings are desired, an easy-to-use interfaceallows for ready population of the access control synchronization map bythe portal administrator to effectuate the desired securityconfiguration. When a new domain is added to the enterprise network, theportal administrator only needs to manipulate settings in the accesscontrol synchronization map, and subsequent user/group synchronizationsand object security importations will automatically populate the objectsecurity table.

According to one preferred embodiment, for a given external object, thepredefined security mapping process comprises the step of forming areflexive set of external users and external groups having access to theobject, each member being expressed as a concatenation of the externaldomain and the external user or external group. Each domain indicated inthe external users and groups is then mapped to one or more portaldomains using the domain synchronization map. Each group indicated inthe external users and groups is then mapped to one or more portalsimple group names using the group synchronization map. A candidate setof all possible pairings are then formed between (i) all indicateddomains, and (ii) all indicated external group and portal simple groupnames. The candidate set is then compared to the user profile table andthe group profile table, and any candidate member not appearing ineither table is deleted. For that external object, the object securitytable is then populated with the remaining members of the candidate set.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an enterprise network and a corporate portal systemoverlaid thereon in accordance with the prior art;

FIG. 2 illustrates corporate portal security administration steps for animported object in accordance with the prior art;

FIG. 3 illustrates corporate portal security administration steps inaccordance with a preferred embodiment;

FIG. 4 illustrates a block diagram of a corporate portal system inaccordance with a preferred embodiment;

FIG. 5 illustrates an exemplary enterprise network in a firstconfiguration for use with a corporate portal system in accordance witha preferred embodiment;

FIG. 6 illustrates database information stored in a corporate portalsystem corresponding to the enterprise network configuration of FIG. 5;

FIG. 7 illustrates steps taken during enforcement of corporate portalsecurity settings in accordance with a preferred embodiment;

FIG. 8 illustrates an exemplary enterprise network in a secondconfiguration for use with a corporate portal system in accordance witha preferred embodiment;

FIG. 9 illustrates steps for mapping external security information intoa corporate portal system in accordance with a preferred embodiment;

FIG. 10 shows an object security table corresponding to the enterprisenetwork of FIG. 8 subsequent to application of the security mappingsteps of FIG. 9;

FIG. 11 illustrates an exemplary enterprise network in a thirdconfiguration for use with a corporate portal system in accordance witha preferred embodiment;

FIG. 12 illustrates an updated user profile table and an updated groupmembership table corresponding to the enterprise network of FIG. 11;

FIG. 13 illustrates an exemplary enterprise network in a fourthconfiguration for use with a corporate portal system in accordance witha preferred embodiment;

FIG. 14 illustrates database information stored in a corporate portalsystem corresponding to the enterprise network of FIG. 13;

FIG. 15 illustrates steps for mapping external security information intoa corporate portal system in accordance with a preferred embodiment, theobject being contained in a newly added external domain;

FIG. 16 shows an object security table corresponding to the enterprisenetwork of FIG. 13 subsequent to application of the security mappingsteps of FIG. 15;

FIG. 17 illustrates steps for re-mapping external security informationcorresponding to an object in accordance with a preferred embodiment,the object having been imported prior to the addition of a new externaldomain; and

FIG. 18 shows an object security table corresponding to the enterprisenetwork of FIG. 13 subsequent to application of the security re-mappingsteps of FIG. 17.

DETAILED DESCRIPTION

FIG. 3 shows corporate portal security administration steps inaccordance with a preferred embodiment. At step 302, the content managerconfigures crawl parameters. At step 304, subsequent to instantiation ofthe crawler, a new object is found in an external domain that meets thecrawl parameters. At step 306, the object is imported into the corporateportal, including the steps of creating of an object ID, creating acorresponding metadata object (i.e., card), and indexing the objectcontent. At step 308, native object security settings are extracted fromthe external domain containing the external object. At step 310, thenative object security settings are mapped into corporate portalsecurity information. At step 312, the corporate portal securityinformation corresponding to the object is stored in an object securitytable of a portal database, as will be described further infra.

FIG. 4 illustrates a block diagram of the corporate portal system 402 inaccordance with a preferred embodiment. Corporate portal system 402comprises a Web server 404 similar to the Web server 128 of FIG. 1, aportal processing object server 406 similar to the portal processingobject server 130 of FIG. 1, and a second data storage server 412similar to the second data storage server 136 of FIG. 1. Corporateportal system 402 further comprises a job server 408 comprising a searchengine 414 similar to the search engine 138 of FIG. 1, and a crawler 416similar to the file crawler 140 of FIG. 1. Additionally, however, thecrawler 416 comprises a plurality of accessors 420 designed to extractinformation from the various types of files and other objects that maybe contained on the enterprise network, e.g., .doc files, .pdf files,.xls files, and other object types. The crawler 416 is extensible suchthat if additional document types are introduced into the future,additional accessors 420 can be added to accommodate them. It is to beappreciated that while the crawler 416 may be referred to as a filecrawler in some examples, the preferred embodiments are not so limited,and the crawler 416 may generally comprise any software or algorithmadapted to detect and/or import external objects or other items into thecorporate portal system.

In accordance with a preferred embodiment, crawler 416 further comprisesthe capability to extract from the file system of a discovered objectthe native security settings corresponding to that object. The locationand format of the native security settings will depend upon the type ofsystem used in the external domain (e.g., NT™, LOTUS NOTES™, SOLARIS™,etc.), and a method of extracting this information will be readilyapparent to a person skilled in the art upon review of the appropriatedocumentation for such system.

Job server 408 further comprises a group of synchronization agents 418that are periodically instantiated to detect the presence of added ordeleted external users on the enterprise network, as well as added,deleted, or changed external groups on the enterprise network. Asindicated in FIG. 4, different synchronization agents 422 are requireddepending on the type of the external domain directory structure beingexamined (e.g., NT™, LDAP™, ODBC™, etc.). In accordance with a preferredembodiment, when a synchronization agents detects new or changedexternal user or group information, it automatically populates the userprofile table, group profile table, and group membership table with thenew information. As will be apparent from the descriptions infra, thesenew users and/or groups are automatically accommodated during subsequentimportations of security settings associated with imported objects,unless optional custom security settings are desired. When optionalcustom security settings are desired, the portal administrator mayinstantiate an easy-to-use administrative interface for updatinginformation in the portal database 424 used to map external securityinformation into corporate portal security information, in a manner tobe described infra.

Job server 408 or data storage server 410 further comprise an internalportal directory (not shown) for maintaining portal user information andportal group information. In general, any type of commercial, custom, orproprietary directory system may be used to store the portal user andportal group information. The internal portal directory is distinct fromexternal directories which lie outside the portal system and which areassociated with their respective external domains. The externaldirectory information may be accessible via NT API calls, LDAP, or viaother means as appropriate. Accessibility via LDAP is relatively simpleto use, and LDAP is often used as a common export format fromproprietary directory systems such as Lotus Notes.

Portal database 424 comprises directory tables 426 similar to thedirectory tables 146 of FIG. 1, and metadata objects (cards) 428 similarto the metadata objects 148 of FIG. 1. While in the preferred embodimentthe portal database 424 is presented as a relational database, it is tobe appreciated that any database system capable of achieving similarfunctionalities could be used, e.g., a functionally equivalent systemcould be built on top of on object oriented database, or on top of aproprietary database type. In accordance with a preferred embodiment,portal database 424 further comprises a user profile table 430, a groupprofile table 432, a group membership table 434, an object securitytable 436, and an ACL (access control list) sync map 438 (hereinaftersynchronization map 438), these tables and maps comprising informationas will be described further infra.

FIG. 5 illustrates an exemplary enterprise network 502 in a firstconfiguration for use with a corporate portal system in accordance witha preferred embodiment, which is used herein to describe preferredpopulation of the security mapping information stored in portal database424. Enterprise network 502 comprises a first domain 504 (“SF”) havingexternal users 506 (Sue, Sarah, Sam) that are members, in differentcombinations, of the groups 508 (Techs, Execs, Mgrs, Retail). The SFdomain 504 further comprises a file object 518 that is an Excel file“1QSalesResults.xls.” Enterprise network 502 further comprises a seconddomain 510 (“PA”) having external users 512 (Paul, Pat, Perry) that aremembers, in different combinations, of the groups 514 (Dev, Topmgmt,Allmgmt, and EndSales). For purposes of this simple example, a commonLDAP directory 516 is provided, and accordingly both domains are awareof each other and their respective users and groups.

FIG. 6 illustrates portal database information stored in a corporateportal system corresponding to the enterprise network configuration ofFIG. 5. For purposes of the example of FIGS. 5-6, it is to be assumedthat object importation and security mapping has already taken place forthe document 1QSalesResults.xls. In addition to being users in their owndomains (“external users”), the users Sue, Sarah, Sam, Paul, Pat, andPerry are also users of the corporate portal (“portal users”). Portaldatabase 424 comprises a user profile table 602, populated with entriescorresponding to each portal user, each entry comprising a concatenationof a portal domain corresponding to the user and the user's common nameas used by their external domain. For purposes of the example of FIGS.5-6, all of the portal users are considered members of the same portaldomain MYCO. A portal domain is essentially a “virtual” domain thatexists only in the portal's own world, and serves as a kind ofauthentication source prefix during the security mapping procedure, andthus the term authentication source prefix may be used interchangeablywith portal domain herein. For clarity of explanation, the corporateportal system of FIGS. 5-6 is in somewhat of a “primordial” state—no newexternal domains or external groups have yet been added. As will be seeninfra, the structure of the information of FIG. 6 accommodates readyextensibility for the addition of new external domains and externalgroups.

Portal database 424 further comprises a group profile table 604populated with entries corresponding to each portal group, each entrycomprising a concatenation of a portal domain corresponding to the groupand the group's common name as used by its external domain. A groupmembership table 606 is also provided which maps portal users intoportal groups according to known group memberships. Generally speaking,the user profile table 602, a group profile table 604, and groupmembership table 606 is usually populated by a portal administrator,although the scope of the preferred embodiments is not so limited andautomated methods may be readily designed for population of these tablesin light of the present disclosure.

Portal database 424 further comprises a synchronization map comprising adomain synchronization map 608 and a group synchronization map 610.Domain synchronization map 608 maps external domains (which will becontained in the extracted native security information for discoveredexternal objects) into portal domains/authentication source prefixes. Ina simplified example of FIGS. 5-6, there are only two entries, in whichthe external domains SF and PA map into the single portal domain MYCO.Group synchronization map 610 maps external group names into portalsimple group names, and comes into play upon the addition of new groupsand/or domains to the enterprise network. Accordingly, since theenterprise network is in its “primordial” state in the current example,the group synchronization map 610 remains unpopulated.

Portal database 424 further comprises an object security table 612 whichis used to enforce the corporate portal security settings in accordancewith a preferred embodiment. For the present example, in which only asingle file has been imported into the corporate portal, there is only asingle object entry together with the portal users and portal groupsthat have access to the object (more particularly, having exposure tothe metadata object corresponding to the external object). It is readilyseen how the native security settings for the external object, whichgrant access to PA/Perry, SF/Execs, PA/Topmgmt, and SF/Retail, wouldgenerate corresponding portal access settings of MYCO/Perry, MYCO/Execs,MYCO/Topmgmt, and MYCO/Retail.

FIG. 7 illustrates steps taken during enforcement of corporate portalsecurity settings in accordance with a preferred embodiment. At step702, a portal user logs into the corporate portal system. At step 704,the portal user performs a search or otherwise browses to an objectexposure point, that is, to a point where the existence of the objectwill be exposed to the portal user if access permissions are met. Atstep 706, portal group membership of the portal user is determined usingthe group membership table 606. At step 708, the OID of the portal userand the OIDs of the portal groups of which that portal user is a memberare compared to the object security table 612. At step 710, it isdetermined whether that portal user, or any portal group containing thatportal user, has access permissions to the object. If not, then at step712 access to the object is denied, and the existence of the object isnot exposed to the user. If yes, then at step 714 the user is allowedaccess to the object and is exposed to its existence.

FIG. 8 illustrates the exemplary enterprise network 502 in a secondconfiguration, wherein a new file 802 “2QSalesResults.xls” is added tothe SF domain. In this example, the newly added file has the same nativeaccess permissions as the existing file “1QSalesResults.xls.”

FIG. 9 illustrates steps for mapping external security informationcorresponding to the object “2QSalesResults.xls” into the corporateportal security system in accordance with a preferred embodiment. Alsoshown in FIG. 9 are data listings corresponding to various stages of thesecurity mapping. Because there are no additional users, groups, ordomains, the security mapping parameters of FIG. 6 are still applicable.At step 902, the external domain identifier and external groupidentifiers for each group having access to the object are received fromthe crawler 416. These are shown as data elements 950 in FIG. 9(PA/Perry, SF/Execs, PA/Topmgmt, and SF/Retail). At step 904, areflexive set of external users and external groups having access to theobject are formed. This results in the dataset 952 of FIG. 9. At step906, a list 954 is created comprising all authentication source prefixes(portal domains) that can result from mapping the external domainassociated with every external group having access to the object throughthe domain synchronization map 610. In the simple example presented,each of the SF and PA external domains simply maps into the MYCO portaldomain. At step 908, again for every external group having access to theobject, a list of all portal simple group names that can be mapped therethrough the group synchronization map 610 is generated. In the presentsimple example, the results are NULL because the group synchronizationmap 610 is not populated.

In accordance with a preferred embodiment, at step 910 a candidate list958 is generated containing all possible pairings of (i) all domains andauthentication source prefixes that resulted from the previous steps,with (ii) all external group names and portal simple group names thatresulted from the previous steps. As shown in FIG. 9, even in thissimple example, there are 12 such pairings. The generated candidate list958 represents all portal entities which, if they exist, should haveaccess to the object. At step 914, any members of the candidate set 958that do not appear in either the user profile table 602 or the groupprofile table 604 are deleted, because these hypothetical pairings donot exist in the corporate portal system. At step 916, the objectsecurity table is populated with the remaining members of the candidateset. FIG. 10 shows the resulting object security table, containing theexpected additional entries 1002. These entries are, of course,identical to the entries for “1QSalesResults.xls” because the nativesecurity settings were the same and because no additional groups ordomains were added between the security mappings for“1QSalesResults.xls” and “2QSalesResults.xls.”

FIG. 11 illustrates the exemplary enterprise network 502 in a thirdconfiguration, wherein a new user 1102 (Peter) is added to the PAdomain. Advantageously, none of the synchronization maps 608 or 610requires modification, nor does the object security table 612. Rather, asingle entry corresponding to the additional portal user is added to theuser profile table (FIG. 12, element 1202) by the synchronization agent418 upon detecting the new user, and the group membership table 606 isalso updated according to the group memberships of the additional portaluser (FIG. 12, element 1204). Proper object access will automaticallyresult when the standard portal security enforcement steps of FIG. 7 areexecuted.

FIG. 13 illustrates the exemplary enterprise network 502 in a fourthconfiguration, wherein a new domain 1302 (“SJ”) is added, a new user1304 (John) is added, a new group 1306 (Board) contained in the newdomain is added, and wherein the new domain contains a new file 1308(“newdesign.vsd”). The new file “newdesign.vsd” has a native accesscontrol list that is simply the single group SJ/Board. The presence ofthe new domain is generally an event of which portal administrators willbe aware from external sources, or alternatively, the synchronizationagent 418 may detect the new domain and new external group and alert theportal administrator. In accordance with a preferred embodiment, a newportal domain (authentication source prefix) “SJ” is created toaccommodate the additional external domain. As shown in FIG. 14, theuser profile table 602 is appended with a concatenation of the portalgroup and the external user name for John (SJ/John), and the groupprofile table 604 is appended with a concatenation of the portal groupand the external group name for Board (SJ/Board). The domainsynchronization map 608 is appended with entries sufficient to ensurethat each external domain (SF, PA, SJ) will map into each portal domain(or authentication source prefix) (MYCO, SJ).

Advantageously, in accordance with a preferred embodiment, the portaladministrator may strategically populate the group synchronization map410 to achieve a portal security strategy appropriate to the newenterprise network addition. By way of example, the new domain 1302 mayhave been added to the enterprise network by virtue of a corporateacquisition of a startup company “SJ” containing one employee “John” orvery few employees, but who nevertheless will end up with a high-rankingposition in the acquiring company.

Advantageously, the group synchronization map 410 may be strategicallymanipulated to achieve the following scenario. While it would bedesirable for all current managers, including lower-level managers in“Mgrs” and “Allmgmt” of the existing company, to view documents to which“Board” members have access, it may be prudent at the outset of themerger to prohibit the converse, i.e., to prohibit “Board” members fromviewing documents to which the current lower-level managers have access.Rather, it would be desirable only to allow “Board” members to viewdocuments accessible by their “Execs” and “Topmgmt” peers. This isachieved by mapping “Board” into all four management groups (Execs,Topmgmt, Allmgmt, and Mgrs) in the group synchronization map 410, butonly mapping “Execs” and “Topmgmt” into Board using this in the groupsynchronization map 410. Notably, Allmgmt and Mgrs are not mapped intoBoard. The resulting security mappings outlined in FIGS. 15-18 readilyshow how this strategic population of the group synchronization map 410achieves the desired access objectives.

Once the portal database 424 is updated to include the new users,groups, and domains, a file crawl process may be instantiated for thedocuments in the new external domain. Optionally, a file crawl processfor existing objects already mapped into the portal system may bere-instantiated to update the object security map for those existingobjects. Alternatively, the next regularly scheduled file crawl can takecare of this. Advantageously, however, no re-manipulation of thesecurity settings of file crawl parameters is required, because objectsecurity parameters are no longer determined by the corporate portalsystem (except in individual override scenarios allowed by the preferredembodiments), but rather the object security parameters are determinedby mapping the native object security parameters into the portal'ssecurity system.

FIG. 15 shows data elements 1502-1512 corresponding to the mapping ofnative security parameters for “newdesign.vsd” into the corporate portalsystem, with the steps of FIG. 9 being reiterated for the convenience ofthe reader. The resulting object security table is shown in FIG. 16. Asdesired, all managers of the existing company (MYCO/Execs, MYCO/Topmgmt,MYCO/Allmgmt, and MYCO/Mgrs) may view the document that is also viewableby the new group SJ/Board.

FIG. 17 shows data elements 1702-1712 corresponding to the re-mapping ofnative security parameters for the already-imported document“2QSalesResults.xls,” with the steps of FIG. 9 also being reiterated forthe convenience of the reader. The resulting object security table isshown in FIG. 18. As desired, after the combinational methods andfilterings of the preferred embodiments are applied, the new groupSJ/Board is able to view the document “2QSalesResults.xls,” as well asthe previous groups that were already allowed to view the document(MYCO/Execs, MYCO/Topmgmt, MYCO/Allmgmt, and MYCO/Mgrs). This is thedesired outcome because Execs and Topmgmt were already able to see thedocument, and SJ/Board has their viewing permissions. It would bereadily seen, using the group synchronization map of FIG. 14, that thenew group SJ/Board would not be able to see documents viewable only byAllmgmt and Mgrs (as desired).

It is to be appreciated that while in the examples supra each portaluser (e.g., MYCO/Sarah), corresponded to an external user (e.g.,SF/Sarah), the features and advantages of the preferred embodiments arealso enjoyed where there are portal users not associated with externalusers. There may well be many users who are users of the corporateportal, but are not external users in an external domain. Thus, in theexamples supra, an administrator could create a new portal user“IvanRetail,” and could put

IvanRetail into the MYCO/Retail group. This user would then have accessto the metadata objects available to persons in the MYCO/Retail group,as well as any new metadata objects created that are based on externaldocuments which grant permission to SF/Retail. Note that this user doesnot represent any external entity, but only exists in the portal domain.IvanRetail benefits from the security mappings of the preferredembodiments, because he is placed in a portal group corresponding to anexternal group.

Whereas many alterations and modifications of the present invention willno doubt become apparent to a person of ordinary skill in the art afterhaving read the foregoing description, it is to be understood that theparticular embodiments shown and described by way of illustration are inno way intended to be considered limiting.

By way of example, while the utility for extracting native securityinformation is presented supra as being part of the crawler, it is to beappreciated that such utility may be provided as a separate component,and may even run on a machine separate from the crawler. By way offurther example, while the examples provided supra are in the context ofthe mapping of group security settings upon object import, the preferredembodiments are readily applicable to the mapping of user securitysettings as well.

By way of further example, it would be within the scope of the preferredembodiments to dynamically access the external security information foran object from its native domain whenever that object initially matchesa user search or request. The prescribed methods supra for mappingnative security information to the portal security system may then occur“on the fly,” thereby obviating or supplementing the object securitytable.

By way of further example, the preferred embodiments supra are readilyapplicable to scenarios in which groupings can be made of groupsthemselves, i.e., in which “groups of groups” are supported. By way offurther example, the preferred embodiments for establishing securitysettings described supra are readily applicable beyond the corporateportal environment and may be advantageously used in the context ofpublic portals, for example, having predetermined agreements with publiccontent providers and user-settable options for invoking differentobject security features. Therefore, reference to the details of thepreferred embodiments are not intended to limit their scope, which islimited only by the scope of the claims set forth below.

1. A method for administering portal security, comprising: extracting anative security setting from a native environment of an object; mappingthe native security setting into a portal security setting associatedwith a portal that comprises a metadata object, the mapping beingaccording to a predetermined process that is executed according to oneor more synchronization maps that map external groups or domains, orboth, to one or more intermediate sets of identifiers and that aremaintained in a portal database; associating in the portal said portalsecurity setting with the object; instantiating a predetermined securityrelationship between the metadata object and the corresponding nativesecurity setting; and granting viewing or exposure access to the objectby a particular user or group, or combinations thereof.
 2. The method ofclaim 1, wherein the native security setting comprises an identity of anentity external to the portal having a predetermined securityrelationship with the object in its native environment, and wherein themapping comprises mapping the external entity into a correspondingportal entity.
 3. The method of claim 2, wherein said predeterminedsecurity relationship comprises viewing access.
 4. The method of claim2, wherein the native security setting comprises the predeterminedsecurity relationship with the object in its native environment.
 5. Themethod of claim 1, wherein said one or more maps comprises: a firstsynchronization map that maps external domains to an intermediate set ofdomain identifiers; and a second synchronization map that maps externalgroups to an intermediate set of group identifiers.
 6. The method ofclaim 5, wherein said portal users are identified by a concatenation ofa portal domain identifier and a user name used by the external domainof the user, and wherein said portal groups are identified by aconcatenation of a portal domain identifier and a group name used by theexternal domain of the group.
 7. The method of claim 6, saidpredetermined mapping process comprising: forming a reflexive set ofexternal users and external groups having access to the object, eachmember of the reflexive set being expressed as a concatenation of theexternal domain and the external user or external group; mapping eachexternal domain indicated in each of the external users and externalgroups into to one or more portal domains using the firstsynchronization map; mapping each external group to one or more portalsimple group names using the second synchronization map; forming acandidate set of all possible pairings between (i) all indicatedexternal and portal domains, and (ii) all indicated external group andportal simple group names; comparing the candidate set to said portaluser and portal group information; and deleting from the candidate setany member not appearing in said portal user and portal groupinformation; wherein the remaining members of the candidate setrepresent the corresponding portal users and portal groups having accessto the object.
 8. A corporate portal apparatus, comprising one or moreprocessor readable storage devices having processor readable codeembodied thereon for programming a one or more processors to perform amethod of administering portal security for an object, said processorreadable code comprising component modules including: a crawler foraccessing external objects in external domains; a security extractionutility for extracting native security information corresponding to theexternal objects from one or more security systems of the externaldomains; and a database comprising information for mapping according toa predetermined process that is executed according to one or moresynchronization maps that map external groups or domains, or both, toone or more intermediate sets of identifiers, and that are maintained ina portal database, wherein the apparatus comprises said one or moreprocessors for performing said method which further includesinstantiating the predetermined security relationship between a metadataobject and the corresponding native security setting, and wherein thesecurity system of the corporate portal regulates exposure of portalmetadata objects corresponding to the external objects based on themapped security information.
 9. The corporate portal apparatus of claim8, further comprising a synchronization agent for accessing externaluser and external group information from the external domains, whereinsaid database comprises information derived at least in part from saidexternal user and external group information.
 10. The corporate portalapparatus of claim 9, further comprising an administrative userinterface for assisting a portal administrator in populating saiddatabase using information that includes said external user informationand said external group information.
 11. The corporate portal apparatusof claim 10, wherein said synchronization agent is adapted andconfigured to extract user and group information from external domains.12. One or more computer readable media encoded with aprocessor-readable computer program product for implementing a method ofadministering portal security for an object, the method comprising:extracting a native security setting from a native environment of theobject; mapping the native security setting into a portal securitysetting associated with a portal comprising a metadata object, themapping being according to a predetermined process that is executedaccording to one or more synchronization maps that map external groupsor domains, or both, to one or more intermediate sets of identifiers,and that are maintained in a portal database; associating in the portalsaid portal security setting with the object; instantiating apredetermined security relationship between a metadata object and thecorresponding native security setting; and granting viewing or exposureaccess to the object by a particular user or group, or combinationsthereof.
 13. The one or more computer readable media of claim 12,wherein the native security setting comprises an identity of an entityexternal to the portal having a predetermined security relationship withthe object in its native environment, and wherein the mapping comprisesmapping the external entity into a corresponding portal entity.
 14. Theone or more computer readable media of claim 13, wherein saidpredetermined security relationship comprises viewing access.
 15. Theone or more computer readable media of claim 13, wherein the nativesecurity settings have the predetermined security relationship with theobject in its native environment.
 16. The one or more computer readablemedia of claim 15, wherein said one or more maps comprises: a firstsynchronization map that maps external domains to an intermediate set ofdomain identifiers; and a second synchronization map that maps externalgroups to an intermediate set of group identifiers.
 17. The one or morecomputer readable media of claim 16, wherein said portal users areidentified by a concatenation of a portal domain identifier and a username used by the external domain of the user, and wherein said portalgroups are identified by a concatenation of a portal domain identifierand a group name used by the external domain of the group.
 18. The oneor more computer readable media of claim 17, said computer code formapping the external users and external groups into corresponding portalusers and groups according to a predetermined mapping processcomprising: computer code for forming a reflexive set of external usersand external groups having access to the object, each member of thereflexive set being expressed as a concatenation of the external domainand the external user or external group; computer code for mapping eachexternal domain indicated in each of the external users and externalgroups into to one or more portal domains using the firstsynchronization map; computer code for mapping each external group toone or more portal simple group names using the second synchronizationmap; computer code for forming a candidate set of all possible pairingsbetween (i) all indicated external and portal domains, and (ii) allindicated external group and portal simple group names; computer codefor comparing the candidate set to said portal user and portal groupinformation; and computer code for deleting from the candidate set anymember not appearing in said portal user and portal group information,wherein the remaining members of the candidate set represent thecorresponding portal users and portal groups having access to theobject.